Is nothing a legal C program? Good question.
To create this entry execute the command touch smr.c To compile and execute it: cp smr.c smr chmod a+x smr smr >srm_new.c
The result is a file "smr_new.c" which contains an exact copy of the source code.
The "other" parts of a program Many programmers write good, quality programs, but fail to add the little touches that are needed to create a good software package.
Consider the installation procedure. It's the first part of the program seen by the user. Yet in many instances, this procedure is left to last and thrown together during the frantic days when the programmers are trying to get the release out the door.
How many programs have you seen where the install instructions read like, "Tar the files off the tape, edit a few of them and then run the program."
Consider things from the customer's point of view. He just bought a brand new $8,000 software package from you that the salesman would solve all his problems. He's eager to get it running and play with his new toy. He opens the box and discovers the install manual -- all 30 pages of it.
It tells him to become root, edit a bunch of files and then restart his machine. He knows that if he makes one editing mistake his machine will crash and burn. By the time he starts the software, he is nervous, frustrated and generally not in a good mood. At this point the software must be very good to overcome installation problems.
Worse, he can evaluating the software. When I evaluate software I have a very limited amount of time. I'll try to install the program once. If it works, fine. If it doesn't, I'll back out all my changes and throw the software away.
What I won't do is call the vendor to try and work out the installation problems. First of all debugging a computer over the phone is difficult and secondly I don't have the time.
On the other hand, there are software packages where time and effort were taken to get the installation right. Installation starts with a simple command or two and then the install program takes over. If there are system files that need to be edited, it edits them (after warning me and giving me a chance to skip the edit).
Okay. Now I've got the software installed. What do I do now? Read the manual and use it? No way. I'm a typical user and I don't read manuals. I want to try out my new toy -- do a test drive, so to speak. For that I need some sample files. Give me something to play with.
Some systems have demonstration runs or test drives. These are good as well.
Next we come to the help system. In general I read the manual as a last resort. Actually, if the software forces me to read the manual I consider it a sign of poor quality. Good help systems take work. They require the input of both a good programmer and a technical writer. Creating a well written, well structured help system is an art and takes time. It should not be left until the last minute.
Bad examples of help systems abound. I remember seeing one system where an entire section consisted of only "TBD" (To be done). Another had a help page that referred me to commands that no longer existed and libraries that were not shipped with the current version of the product.
One thing you should never do is to try and put in a help system at the last minute. I've actually told a client that his help system could be greatly improved by one simple change: remove it! The problem was that the program's help system was so bad that it was unusable. In other words, the help system was no help. But it was there and the poor help system made the rest of the program look poor.
I do use the manual now and then. Mostly when I get an error and want to see what to do about it. Nothing annoys me more than trying to find the meaning of an error message and discovering that there is no section in the manual that covers errors.
Making a complete manual is not an easy task. Programmers are adding new error messages all the time and they don't take the time to inform tech pubs about them. The result, unless a strong effort is made to get all the errors in the manual, the manual will be missing some messages. The worst part of this is that the new errors are the ones most likely to be found by the user. The result is that the user is frustrated and technical support has to deal with a lot of expensive calls.
In short, the actual code is only one part of the total program. True it's the part that most engineers focus on, but by widening their horizons, they can create much better total programs.
IBM has adopted an interested strategy toward marketing OS/2. The current version is being sold extremely cheaply. The idea is to get people using OS/2 and then charge for upgrading to the new version when it comes out.
But one fundamental question remains: If OS/2 is so superior to Microsoft Windows, why is IBM having so much trouble marketing it? After all, didn't Ralph Waldo Emerson say: "Build a better mousetrap and the world will beat a path to your door?" (Paraphrased)
The problem is that this myth: "build a better mousetrap" is wrong. You can build the best mousetrap in the world and if you don't market it right and sell it, you'll go broke. IBM knows that and that's why they are trying everything to sell OS/2 including giving out cheap copies.
(Actually, I got my OS/2 for free. IBM was handing them out at a trade show. I bought an official copy so I could get the manual.)
In school computer engineers are taught, "Your job is to create the best possible program you can. The programmer making the best program gets the most money."
I used to believe that. Then I worked for a while at Tandy Electronics. They make software and computers for a little retail outfit called "Radio Shack." Now one thing people agree on, Radio Shack didn't have the best hardware and software around. Especially back in the days of the TRS-80 Model 1. But if there was anything that Radio Shack was good at it was selling.
The fate of your product -- whether or not it got into the store -- was controlled by a person called the "buyer." The buyer didn't care about how technically advanced your program was. What he or she did care about was whether or not it would sell. True, the more advanced programs tended to sell better, but this was not always the case. For example, Unix is far superior to MS-DOS, but Radio Shack decided to go with MS-DOS because it figured that more people would want to use it.
I once performed a demonstration for the head of Radio Shack. The first words I heard out of his mouth were "Show me something I can sell." That made a big impressions on me.
The world does not revolve around the software engineer. It revolves around the salesman. Sales bring the money into the company. It's the job of the Software Engineer to give the salesman a good product to sell.
One thing you need to be aware is how long you've got to convince a customer to buy your software. At Radio Shack, that time is measured in seconds. How can you convince someone to buy your program in such a short time? First of all you need a good demonstration mode.
One thing I noticed about salesmen: They didn't care a whole lot about how the program performed, but they did care about the demonstration mode. After all, they aren't showing the customer the program, they showing the demonstration. So actually the customer is buying the demonstration. The actual software is there so he or she doesn't return the package in the morning.
In addition to a good demonstration, you'll need good documentation. I've always been amazed at some business organizations. They wouldn't dream of letting the cleaning woman do programming. Someone from the accounting department would never be allowed to draft legal documents. And no way would they let a programmer fill in for a CEO even though a programmer is cheaper. Yet these same companies let software engineers write manuals.
Writing is an extremely difficult art. In some ways it's harder than writing code, after all the computer crashes when you code wrong. If a program doesn't have a good manual, the user can't use it. Well written documentation sells the program.
Suppose I buy a program to solve a particular problem. I'm going to measure how good this program is by how long it takes me to solve my problem. I'll start by looking through the user's manual to find the command that I need. I'll look at the index and read just what I need. Sometimes I'll look at the table of contents, but that's rare. Most of the time it's index only.
But what if the manual doesn't have an index? I don't buy it. But what if the manual doesn't have an entry for what I'm looking for? I search a bit, curse a bit and if I find what I'm looking for fine. Otherwise the program doesn't get used. (When I index one of my books I try and put in index entries for everything. Take a look at the index for C Elements of Style and you'll find an index entry for the kitchen sink.)
Proper organization and indexing of a manual is extremely important. It's also important that this be done by a writing professional. Programmers think like programmers. Writers tend to think more like human beings. They are trained to fill in things that programmers take for granted.
Programming is a team effort. The team must include not only software engineers, but also marketing, sales, writing and management. As programmers you must work with the other members of the team to sell your work. Remember it selling that counts.
Unfinished business
People have asked me to publish the address of the Free Software Foundation. Here it is:
Free Software Foundation 675 Massachusetts Avenue Cambridge, MA 02139 (617)-876-3296
You can get the g++ compiler and other GNU software through anonymous ftp from prep.ai.mit.edu, directory pub/gnu.
But if they are so bad why do people still program in them? The answer is that when the project was started they were the best programming languages for the job.
Take my project, for example. All they wanted was one program to create a distribution tape and another to install it. Turns out that creating a tape can be done easily with a few lines of shell programming. And it's the same when it comes to installing it. It takes just a few tar commands. This can easily be accomplished with about five lines of shell program.
So how did that five lines of program grow into something with more than a thousand? It turns out a few features were added to the system, several of them new. Each one could be individually put on tape and individually installed. Also the install script was expanded to do disk size checking as well as distribute the product's components across multiple disks.
Finally it was decided that we would support not only Sun machines, but also Silicon Graphics and Hewlett Packard computers. Suddenly we needed a great deal of machine-dependent code.
Shell programming is supposed to be "standard." It's not. For example, the command "echo -n" must be done differently on each machine. The result is that all these little features add up and soon you're no longer dealing with a 10-line script but one with 1,000 lines.
I estimate that shell programming is about 5 times more costly and 10 times more risky than C++ programming. (The method I used to derive these numbers is called in scientific circles "an educated guess." So don't give me a hard time about these numbers.)
Clearly we want the install script to be one of the most reliable parts of the product. After all that's the first thing the customer runs. I've thrown evaluation products in the trash simply because I couldn't get the install procedure to run after five minutes of trying.
Given a choice of a 1,000-line shell program and a 2,000-line C++ program any sane manager would choose the 2,000-line C++ program. So why am I debugging a 1,000-line shell program?
The answer is that we didn't set out to write a 1,000-line shell program. We set out to write a 10-line shell program. Then another feature was added making it a 20-line shell script. And another feature, and another feature, and so on until you had a 900-line shell script.
It all makes me want to burst into song:
100 lines of code in the script
100 lines of code
Take it down
Change it around
110 lines of code in the script.
Soon we reach the point where we're adding another feature to a 900-line shell script. Management is now faced with a decision: "Do we add another 50 lines to the shell script at a cost of X or do we rewrite it the entire install into a 1,800-line C++ program at the cost of 5X?"
The answer is obvious: "X < 5X", so edit the shell script. What's not in the equation is the long term cost. It cost X to add a feature to the shell script and X/2 to add one to a C++ program. For 20 features, shell maintenance costs 20X and C++ maintenance costs 10X.
There's one other factor at work here. When coding is complete on a new product, everyone in the company absolutely, positively must have a copy of it now. They can't wait a week or two until you get the software manufacturing and install procedures worked out. They must have it and they must have it now ! The result is that there is tremendous pressure to get the product out the door quickly. As a result there is not enough time to do a proper job on the installation procedure. I believe that every manager should have a sign posted above his or her desk: "Why is there never enough time to do it right, but always enough time to do it over?"
I have a solution to the problem of the rush to beta and production. The company should have two beta release dates. The first is a closely guarded secret told only to the programmers. It is the day the programmer thinks he or she is going to be ready for beta. Under no circumstances should anyone in management be told this date.
The other date is the one supplied to management and the outside world. It should be at least a month after the programmer's release date. That way the programmers get at least half a month before management starts pressuring them for the software.
In closing I would like to say that there is one nice thing about shell programming. It feels so good when you stop.
Display and printer technology have improved considerably over the years. Today anyone can easily afford a word processor that will allow him or her to create beautiful documents. The documents can contain a wide variety of fonts and type styles. The user can even input graphics...unless the document is a program. In which case the user is stuck with straight ASCII. That means 10 point courier and nothing else.
There have some efforts to typeset programs. The Unix program "vgrind" will start with C source, typeset it and print it. However the problem with this is that this is not a WYSIWYG system. The programmer types in his programmer using a fixed width font, runs it through vgrind and then is very much surprised to see that all his comments are screwed up. Because vgrind uses a proportional font all the spacing inside the comments is changed.
Borland-C++`s built-in editor will color the various elements of the language different colors. The colors are useful when editing, but there is no way to print them.
These two methods have one thing in common. They take ordinary ASCII code and try to pretty it up. Why can't someone merge a compiler with a word processor and let the programmer free to use his or her imagination in programming?
One thing I've always been interested in is good programming style. I believe a good program should not only be correct but also be readable. One of the problems with most of the programming courses today is that they train the programmer to write correct code only. Also, since most assignments are only a few pages long, programmers think that they can understand any program, no matter how uncommented, just by looking at it.
For example, here is a sample from a piece of code I recently acquired from the net:
int
v_cht(sp, ep, vp)
SCR *sp;
EXF *ep;
VICMDARG *vp;
Figuring out what this code does is not the easiest thing in the world.
Style checkers exist for English text. Run them on a paper and you'll get all sorts of statistics telling you about the readability, sentence length and complexity of the document.
We need a good style checker that computes a readability index for C programs. Now I realize that good style is difficult to define, but I think it would be fairly easy to write a program that would distinguish between horrible programs and programs that adhere to a minimum required style.
I'm not talking rocket science here. I'm talking about putting comments at the beginning of each function, adding comments after each variable declaration and using decent variable names.
I would also like to see a program that could compute a complexity index for a program. After the more nested statement and levels of parenthesis used, the more complex the program. In the real world simple sells.
This program could also analyze the complexity of the connections between modules. Good modules will have a minimum of connections.
Finally we come to risk analysis. Few if any programmers consider risk when designing their program.
I can imagine the following conversation between a tourist and a programmer:
Tourist: "How can get to the bottom of this cliff?"
Programmer: "Jump. That's the fastest way down."
Tourist: "Are you kidding? That's a 200 foot drop! The fall will kill me!"
Programmer: "Don't worry, if you get hurt, we'll fix you in the debugging phase."
Taking the path down may be slower, but it's much less risky. Software metrics are still in their infancy. The statistics we can measure are limited and we're not sure what the results mean. This area is wide open for future development.
One user reaction really annoys me. I hate it when people say, "Our computer won't let me do that." My reaction is, "O.K. We know that in this organization the computer out ranks you. Let's start working our way up the command chain and see if we can find someone who out ranks the computer."
The attitude that things can't be changed or can't be done because of the computer really annoys me. Sometimes people get around the computer in interesting ways.
For example, a school teacher was taking a group of about 50 students on a outing. They decided to take lunch at a local restaurant. To avoid arguments over money, the teacher insisted that everybody ask for separate checks. When the got to the restaurant, the head waiter told them, "I'm sorry, but our computer only allows us to write one check per table." The teacher took this in stride and announced to the class, "All right everybody, only one person per table." The head waiter upon seeing his restaurant filled with tables containing only one person decided that he could give the students separate checks. He was a little ticked off because he had use his "backup" method of handing checks -- he had to add them up by hand.
Another time two friends, a man and a woman, went out to have lunch at a five star restaurant. She had a gift certificate for $20.00. However her meal cost more than that so she decided she was going to pay the difference in cash. He wanted to pay for his entire meal separately with a credit card.
So when the waiter gave them the check, they gave him a gift certificate, cash and a credit card. The waiter took it into the back and returned a few minutes later. "I'm sorry I can't take this," he said. "Our computer will accept only one form of payment."
The man was more than a little annoyed by this. "This is a five star restaurant," he said. "I expect five star service. Take it back and don't bother me about your clerical problems."
Errors can be funny. One fellow received a bill for "$0.00." He sent a nice letter to the company telling them how ridiculous this was and they promised to fix it. Next month he got a bill, past due, for "$0.00." He tried all sorts of things to get the company to remove this bill. He tried letters, he tried phone calls, he tried everything. Each time they would faithfully promise to take care of it and each month he would get another bill for "$0.00." He even defaulted on it and had a 10% penalty added on, bringing the total up to "$0.00."
Finally he got fed up and wrote them a check for "$0.00." The bills stopped.
Computer problems can not only be annoying, but sometimes they can painful as well. I can personally attest to that.
I have a medical problem that requires minor surgery to correct. Before I can get the surgery done, I needed to have a CAT scan done. Normally it takes about two days to get a CAT scan scheduled. It took me three weeks. Seems that the hospital was upgrading its computer system and couldn't schedule anyone until they got the new system working.
I guess no one was supposed to get sick while the computer was down.
There is an attitude running through all these stories that I detest. It is "If the computer won't let us do it, then it can't be done."
I like it when people actually think and come up with ways of getting around the computer.
One company which does this well has a person with the unofficial title of "Un-Goofer." His official title is more impressive sounding, something like, "Senior Accounts Adjustment Officer," but everyone calls him the "Un-Goofer." His job is to correct any goofs the computer makes.
McHenries Auto Repair in San Diego also came up with a novel way of getting around the limitations of the computer. Their billing computer had no section for "notes". That didn't stop them from putting one in however.
I got a bill from them and under the "Parts" section it listed a part named "Called customer with new estimate", price: "$250.00" quantity: "0", extended price "0".
I asked them about this and they said, "We called you with a new estimate and wanted to note it in the bill. Since we put in quantity 0, it doesn't add anything to your bill, but we do have a record of it." So it turns out they did find a way of putting in a note after all.
As computer programmers we have a responsibility to make sure that we run the computers instead of the computers running us.
This means designing a program so that the user can use it in all sorts of situations. Many times we write a program based on our model of what the user will do. Frequently this is wrong.
From time to time surprising things do come up. After all, how often do does someone try to pay for a meal using three different forms of payment?
But there are some things even the best programmer can't anticipate. You can say, "Expect the unexpected," but if you expect something then it's not unexpected. But you can program for the unexpected by putting code in your programs to allow the user to handle the unexpected. In other words, there would be a field in the data saying, "Enter here anything that the programmer forgot to include in the original program."
Finally errors do occur. Programs need to be flexible enough so that someone can go in there and correct them. Good programs should always make sure they can work with the "Un-Goofer."
The result was that I wound up sending in three different problem reports to the three computer manufacturers.
I asked SGI for the location of some prototypes. I also asked where the symbol _SVR5_TIRPC was documented. They got back to me within a couple of days with the correct answer. They also didn't call me an idiot for asking. (I felt like an idiot when I found out where things were.)
I asked HP, "How do I get RPCGEN to generate C++ compatible code?" HP returned the call within a few days. Because of the internal chain of command at my company, the call had to be handled by our system administrator, Cheryl.
The HP representative gave my problem report the idiot treatment. That's where the customer service representative says, "Your guy must be an idiot for asking such questions. Doesn't he know anything about RPC."
The HP guy is reported to have told Cheryl, "You might want to have the engineer read up on RPC. There's a pretty good O'Reilly book on the subject."
"Do your realize that this person writes books for O'Reilly?" Cheryl responded.
"Oh," answered the HP rep. "I think I'll go and get some more information and get back to you later."
Thank you Cheryl, that's the best comeback line I've heard this year.
A few more days passed and Cheryl was told to apply a number of patches to our HP system. Cheryl tells me that HP is very good about the quality of the patches they supply. She knows of only one four-hour period when the HP server contained bad patches. Unfortunately, that's when she download the patches for our machine.
Our HP system crashed -- hard, stone-cold dead, crashed. The system had to be rebuilt from scratch. Finally, the correct patches were applied and we still couldn't get RPCGEN to create the proper code.
We asked HP about this and we were told, "Oh, we made a mistake; We won't support C++ until the next release, sometime in 1996. Why not use RPCGEN on the SUN, and copy the code to the HP?"
Sun took it's time handling my problem report to them. Actually, I had about eight different questions for them. Sun called me a week after receiving the problem report from our system administrator to ask what the problem was. I didn't say, "Exactly what we described in the initial problem report." Instead, I told them that because so much time had passed, that I had answered six of the questions myself. I restated the other two. Two weeks passed. The Sun representative called me and said that they were going to put in a conference call to the engineer. The engineer was not in, so I never talked to him.
More time passed. I finally got a fax from Sun two weeks after that. They gave me answers to both my remaining questions. The questions were:
The second answer was nice, but there was one little problem. It was obviously wrong. I informed our system administrator about the problem and he contacted Sun. Two more weeks passed. My column became due. I'm still waiting for Sun to call back with the correct answer.
The good news is that I was able to quickly find workarounds for the problems I was having with the various systems. I decided to send the problem reports "through channels" to see what it would take to get a real answer from the various computer companies' bureaucracy. Besides, it is good training for dealing with my insurance company.
Surprises in the mail
I write these columns well in advance of their publication. A number of you wrote in commenting on my April column, "Don't get bullied by your computer." This causes me a little confusion. You see, I don't write the titles to my columns, so I couldn't place the name. It took a little digging through my archives to figure out what these readers were talking about. Oh well. That's what happens when you live in a two-month time warp. I welcome e-mail from my readers and am always on the lookout for columns that will interest you. Let me know what you like and dislike.
In the early days, the I/O device of choice was the ASR-33 Teletype. It was slow, clunky, but relatively cheap. Interface it to a computer and the machine could ask you questions and you could type in your answers. All in upper case only. (Lower-case terminals cost a lot of money back then.)
Later, CRT technology became popular. With the addition of positioning control, you could design forms and do full-screen input. Also, the CRTs were much faster, so not only could you input the data easier, you could get the answers faster.
With the invention of personal computers came a new innovation -- cheap graphics. Later -- much later -- came the software that allowed programmers to easily use this new capability. Starting with Apple's Macintosh and later with MS-Windows 3.0, people started designing graphical user interfaces (GUIs).
GUIs started an interesting trend. Everyone decided that GUIs were the way to go. Major software publishers starting rewriting their applications to use the new interface. It seemed that every application had to have a toolbar with lots of neat icons up there.
Every command turned into icons. It looked neat. The trouble was that not every command can easily be represented by an icon. For example, you can easily think up icons for "Print," "Cut" and "Paste." But how about "Rename," "Undo" and "Page Size?"
Just for fun, go to your computer and fire up your favorite word processor or spreadsheet. Take a look at the icons along the top and see if you can name all the commands.
What's happened is very interesting. In the rush to use the latest and greatest technology, designers forgot about the end user. Instead, they designed something that looked great, sounded good and is extremely difficult to use.
An interesting solution to the problem of the unknown icon has popped up. Now when you position the cursor over the icon, a message pops up telling you in English the meaning of the icon. Of course, you could design the interface using English words in the first place, but then your application wouldn't have all those neat little icons all over the place.
More $0.00
A while ago in a column titled "Don't Get Bullied by Your Computer," I told a story about a man who received a bill for $0.00. He tried and tried to get the problem corrected and couldn't until he finally sent in a check for $0.00.
I recently got an e-mail from someone who once had that very problem. And he solved it by writing a check for $0.00.
But that's not the end of the story. Shortly after sending out the check, he got an irate call from his bank. "Did you write a check for $0.00?"
"Yes," he said hesitatingly.
"Why did you do such a thing?" the teller exclaimed. "Do you realize that your checked triggered an internal consistency check in our system and crashed our computer?"
He responded, "Hey, the supplier's computer requires a check for $0.00. Yours can't stand it. I'll let you get together with my supplier and work it out."
Last month I wrote about three problems I submitted to three different manufacturers. The one I submitted to Sun was still open when I wrote last month's column. Since then, my system administrator has been continually nagging Sun about this bug report.
Last week I called up the local Sun hardware guru with some questions about my 3/260. When I introduced myself he said, "Oh, so you're the one. We're still trying to find out what's happening with your problem report."
Well, the problem report is now closed. Sun admitted that they have a problem and have written a bug report. Of course, this is a minor bug and they just froze the next release so it may be some time before they fix it.
Today I found some more problems with Sun's header files. Maybe I should submit a problem report...
New book
My new book "Practical C++ Programming (O'Reilly and Associates)" came out in June. For those of you who are trying to learn C++, this is a good introduction to the language and real-world programming.
In college, my father studied chemical engineering. This has always been a numerically intensive field and at that time all the calculations were done by hand or slide rule. Shortly after my dad entered the workforce, computers began to infiltrate his business. He told me about the first time he saw a computer output. There was his colleague with this beautiful automatically drawn graph illustrating a chemical process. In order to produce a similar graph, my father had to compute a bunch of points by hand and then draw the graph himself.
He thought that this output was wonderful, until he saw the program -- a plug board. Back then you programmed a machine by literally rewiring it. In order to make this easier, you were supplied with a special board containing a lot of plugs and a bunch of jumper wires. Connect the proper plugs with the wires, put the board in the machine and you have a program.
A short time later, things like punch cards and high-level languages were invented. I was growing up at this time and had just reached the age when I was asking a lot of questions. "What's two and two?" I would ask.
"Four"
"What's four and four?"
"Eight"
"What's eight and eight?"
This would continue until my father gave up. However, one day he showed me his first Fortran program. When he ran it, the program printed:
1+1 = 2
2+2 = 4
4+4 = 8
and so on till the numbers got too big for me to understand.
My father later went to work for Texas Instruments. He was there when TI invented the integrated circuit. One of the projects he worked on was the first hand-held calculator. There were some interesting problems to solve, like how do you put hundreds of transistors on a chip, especially given the fact that the reliability of the early chip-making process was so low?
The answer: put several hundred on and then let a computerized control system find the ones that work and connect them. The other problem was how to generate the output. This was well before the discovery of the LED. The solution was a thermal printer.
This calculator never made it to market. In fact, when calculators finally did make it, market electronics had changed so much that none of the technology used for that first calculator ever saw the light of day.
When I was 11, my father took me down to his work place and let me write my first assembly language program. We added 2+2. And the result was 2. That's right, my first assembly language consisting of only one instruction had a bug in it.
I wasn't the only one who created buggy programs. Sitting on top of my father's desk was a piece of glass he called his $10,000 desktop. It was supposed to be a photo-plot of a new memory chip. Since plotter time was so expensive, he checked his program every which way he could. Every point was double checked. It took the whole day -- $10,000 worth of photo-plotter timer to produce the thing. Everything went perfectly. Hundreds of lines and points were precisely laid out. Finally, at the very end, the plot was done and the program told the plotter to return to (0,0) with the light on. This put a big black line across the whole plot, thus making it useless for laying out a memory chip, but creating a good conversation piece.
Just after the integrated circuit was invented was a hectic time for the computer industry. There were hundreds of computers and languages out there all trying. Gradually there was a shake-out among the languages and two winners emerged: Fortran for scientific programming and Cobol for business. I started programming for real at this time. Back then, hard disk drives cost thousands of dollars. Floppies had not yet been invented. The main storage media for small computers was paper tape. I'll say one thing about paper tape, it does teach you a lot about file handling. For example, you learn that an assembler makes two passes over the file because you have to manually rewind the tape between passes.
My father soon left the world of business and started teaching. I helped out once and a while and remember one class when he announced, "You know this is probably the last class where I'll have to teach the slide rule." It was. The following semester most of the students had pocket calculators.
When my father entered teaching, the computer world entered the age of the microprocessor. A short time later, MITS decided to put one in a kit and thus invented the personal computer. However, the personal computer revolution really caught fire when IBM came out with the PC.
Suddenly, personal computers were everywhere. After a while, they even entered markets in which you'd never expect to find a personal computer. My mother bought one. Teaching my mother how to use the computer was one of the great challenges of my father's life. He would spend hours explaining things to her like the function of an operating system, the design of the file system and elementary computer architecture. All the while, she would be saying, "Don't tell me about all that. Just tell me what button I have to press to print!"
Clearly, they approached computers from vastly different directions. Because he started working on primitive computers, he had to learn the internals of the machine and the software in order to get anything done. My mother was using a Mac and could remain blissfully ignorant of the details and still get her reports out. It took a while for my father to adjust to the fact there were "dumb users" out there and that he was living with one.
My father never stopped learning. His latest project was to learn C++. He was working with me on the "Teacher's Guide to Practical C++" when he died on May 21, 1995.
His colleagues at East Texas State University have set up a computer science scholarship in his name. Donations may be sent to:
ETSU Foundation
C. M. Oualline Fund
P. O. Box 3425
ET Station
Commerce, TX 75429